Amazing. I was told by someone that this hole is "well known" and has been discussed on the LINUX security list for a while now. A few people have emailed me telling me what it was too, so it is obvious that this is "known" about. I am now even more a believer of full disclosure. We purchased a commercial version of LINUX just a little while ago, and the hole exists. How am I supposed to protect stuff if I don't even know about it? Sigh.... OK, here it goes... Ya know how you put +, -, and @ entries in /etc/passwd to incorporate stuff from an NIS map? Well, you can login with that entry too. + is a damn easy login to try, since most /etc/passwd files using NIS use an entry like... +::::: ... as the last line. This is why just disabling NIS is not enough. If you forget to remove these entries from /etc/passwd, you are screwed. The fix is to put a * in the password field of the NIS entries. This prevents login from the local /etc/passwd but doesn't lock the incorporated NIS entries (a bit inconsistent, but oh well) example: +:*:::: CERT advised me of the above fix. They couldn't test the fix since they don't have a LINUX machine anywhere. Pretty incredible that no one at CERT runs a free Unix that can run on a 386 with 4 megs... Sorry this is posted so close to the weekend (thurs at 17:15 UT). Hopefully it will clear the bugtraq mailer and get out to everywhere by Friday, even though it is already Friday at some parts of the planet. :-( I was going to wait until Monday, but if it is already known, it should be known by all.